Maeiee Weekly No.13：Flutter 动态化、Emacs 知识管理、Weekly 总结
前言
本周主题内容：
- Flutter 动态化，运行在 Dart 虚拟机里的 Dart 虚拟机（嗯？
- Emacs 的知识管理生态调研
- 相见恨晚的 Joplin 笔记软件
- Weekly 复盘
Flutter 动态化
Flutter 官方不支持动态化，逼着第三方探索出各种歪招，具体有哪些招参见《做了2个多月的设计和编码，我梳理了Flutter动态化的方案对比及最佳实现 · 语雀》。
因为工作需要，我也在研究此类技术。我研究的是其中的一种：手写一个运行在 Dart 虚拟机里的 Dart 虚拟机。
突然发现，自己误打误撞进入【编程语言】领域，终于有机会研究这么高大上的东西了！
《Flutter 动态化热更新的思考与实战》
这是网上的一个系列文章，讲解了这一方法的具体实现。这个系列讲得非常好，我就是跟着教程一步步实现出来的。
我的阅读笔记如下：
《Flutter 动态化热更新的思考与实践 - 掘金（2020-04-07）》
- Flutter 本身不支持动态化（Release）
- 为 Flutter 添加动态化：
- 手写 Dart 运行时（编译器 + DartVM in DartVM）
- 本质：在 AOT 上实现一个轻量级 JIT 动态执行引擎
- 优点：
- 跨平台，通用性强，对底层侵入性小
- 缺点：
- 性能：AST 不能过于复杂
- 桩：业务提供便于解析的标准化组件
- 架构设计：
- ASTWidget：动态下发解析 UI
- ASTBLoC：动态下发业务逻辑
- ASTRuntime：运行时，解析、执行 AST，胶水
《Flutter 动态化热更新的思考与实践（二）----Dart 代码转换AST - 掘金（2020-04-11）》
- Dart 代码转 AST（抽象语法树）
- Dart Analyzer 库：官方提供，Dart 代码转 AST
- Analyzer 使用方式：
- Analyzer 提供方法：
- parseFile 传入文件进行解析
- CompilationUnit：解析结果，未处理的编译单元
- Analyzer 提供方法：
- Visitor 访问者模式：
- 遍历语法树
- 常用：SimpleAstVisitor、GeneralizingAstVisitor
- 文章给出了一份示例 Analyzer AST 生成实现
《Flutter 动态化热更新的思考与实践（三）---- 解析AST之Runtime - 掘金（2020-04-22）》
- Runtime 动态解析 AST 并执行
- 手动实现变量栈，管理变量生命周期
- 每个 AstNode 都对应一个执行方法
我的感受
这套方案整体由 3 个部分组成：
- compiler：Dart 转 AST，并序列化
- runtime：运行时，解析 AST 执行 Dart 代码
- 插桩：桥接 Dart 宿主代码，包含 Flutter 框架和自己的代码
实践过程中我的感受如下：
首先，借助于 Dart 官方的 analyzer，compiler 还是很好实现的，这一部分难度不大。
但是从 runtime 开始，问题就变得复杂了。Dart 所有的语法都需要手动开发一套实现，工作量非常之大，难度也很高。开发完成以后，如何测试，如何保障性能都是问题。
假设越过了 runtime 这道坎，插桩部分又是一个难点。什么叫插桩呢？即虚拟机沙箱环境如何与外部虚拟机互操作性。由于 DartVM 在 AOT 下没有反射的能力，所需要的互操作性都需要在编译时，通过代码生成的方式预埋，这也是很难的。
里面还有一个大坑：Dart 自身是处于迭代中的，比如空安全的引入，比如 Swift 互操作性。每当版本更新时，我们都要升级适配，而每次适配的成本都相当高。在以短期 KPI 为导向的团队中，这种持续性高人力投入是不被接受的，烂尾是必然结局。
因此，我个人的看法是，与其搞 DartVM embedded in DartVM，不如搞那些经典的、不再变化的语言，比如 Scheme 或者 Java8，或者发明自己的语言。
Emacs 知识管理扩展
调研了一圈 Emacs 下的知识管理生态，内容如下：
- Obsidian 笔记的 Emacs 前端
- 底层还是 Obsidian，结合 Obsidian、Emacs 两者优点
- 流行的笔记方式：Zettelkasten
- org-brain：建立知识网络，基于 org-mode
- org-roam：对标 Roam Research
- org-roam-server：知识网络可视化
- org-roam-ui：前端可视化展示
- Zettelkasten 方法的 Emacs 实现，star 45
- 两个包：
- org-zettelkasten：基于 Org Mode
- zettelkasten：完全的从头实现（Org 或者 Markdown）
- 相似框架：
- Zetteldeft：使用 Deft 作为后端
- org-roam：基于 wiki 系统的笔记系统
- org-brain：类似的笔记系统
- Zettelkasten 方法的 Emacs 实现，star 370
- 对 deft 包的扩展，使之成为基本的 Zettelkasten 笔记系统
zk.el - A dead-simple, feature-rich Zettelkasten implementation for Emacs
- star 76
- 实现 zetteldeft 包的功能，但是不依赖 deft
My Zettelkustom (with Emacs, of course)
YouTube：Build a Second Brain in Emacs
- For Notion,OneNote,Bear,Yuque,Joplin。Clip anything to anywhere
- Web Clipper
我的感受
各个方案种，org-roam 是目前热度比较高的。
Org Mode 是 Emacs 中个一大宝藏，相当于一个增强版的 Markdown，同时提供丰富的 SDK 供用户定制。很多知识管理扩展都以 Org Mode 作为基础。
Emacs 进行知识管理的优点有很多，比如本地化无需服务器（这既是优点也是缺点，根据需求不同），纯文本编辑（既是优点也是缺点），强大的定制能力（优点适合高级玩家，缺点小白无所适从）。
从上面的表述中，我发现这些优点都不是那么“明显”，甚至换个角度就成为了缺点。我想，原因在于这套系统不是为所有人准备的。而只是给那些明确自身需求，并希望工具完全顺手，同时愿意付出累年精力去打磨的 Hackers。
说到缺点我觉得在编辑体验上。现在的用户都被 Notion 惯坏了，而 Org Mode 还像 LaTeX 一样的体验，有些过时。尤其是图文混排、公式编辑上，体验较差。
如果说 Org Mode 有一个所见即所得的 Emacs 书写环境，以 Web 前端作为 Frontend，能够实时预览，就太棒了。
Joplin
我一直在寻找网页离线化方案，包括之前调研的 PyScrapbook。直到我意外发现 Joplin，这就是我想要的。
Joplin 本身是一个 Markdown 笔记软件，具备一定的开放性，可以进行二次定制。
Joplin 有一个配套的浏览器剪藏插件，能将网页转换为 Markdown 进行保存。这个插件实现的质量还是非常高的，实际转换效果令我满意。尤其是对于图片的处理，Joplin 会将图片保存到本地来展示，这一点对于离线化非常重要。
之前我一直陷入了一个误区：以为网页归档就是要 100% 缓存并还原 HTML 布局。使用 Joplin 后我突然领悟，内容才是重要的。
我现在最常用 Capture Selection 这个功能，把网页中的关键内容存下来，然后添加几个 Tag，便于未来检索。
至此，我的互联网信息剪藏方案尘埃落定了。
Weekly 复盘
最近几周，我在尝试每周给自己设立一个有挑战性的目标。
取得了一定的效果：效率和专注力明显提升，不断取得进展。
同时也发现了一些不足：主要是在知识沉淀上，一周的时间只够我写完周报，这样我就没有时间在 Wiki 中搭建知识体系。我认为搭建知识体系是更加有价值的事情。
时间是有限的，这是一个取舍问题。因此未来的周报形式需要进一步调整。
周报以分享资讯为主
将周报恢复到资讯+笔记的形式。
概括来说：周报记录了我每周看的文章。
知识体系驱动的每周学研
之前我以项目驱动，虽然进展很快，但是不太好，犯了意义综合征的问题。
未来我希望以知识体系驱动，有什么区别呢？
- 项目驱动：必须完成项目目标，不重视知识体系建设
- 知识体系驱动：优先搭建知识体系，项目目标可以达不成
两种方法中，哪一个更加扎实，已经不言而喻了。
增加资讯分享、博客更新频率
还是希望增加资讯分享的频率。规划中：
- 日常看到好文章分享
- 知识体系更新分享
- 周末周报汇总分享
趣味性更强一些，乐趣也更多一些。